fix(dicom): reject chunks that do not fit the volume buffer - #931

Problem

A series whose instances disagree on Rows, Columns, or SamplesPerPixel is still
grouped into one volume, and that volume's buffer is sized from the first
instance. Each decoded chunk was written into a slot computed from the series
dimensions, with no check that it fit.

An instance decoding larger than its slot made TypedArray.prototype.set throw
RangeError: offset is out of bounds, naming neither the file nor what was
wrong with it. An instance decoding smaller wrote entirely inside the buffer and
raised nothing at all: the frame is smeared across the top of a larger slot,
silently. The silent case is the more serious one.

The guard already in place covered only a multi-frame instance inside a
multi-file series.

Change

dicomChunkImage.ts computes the slot each chunk may occupy, one frame per
chunk in a multi-file volume and the full depth for a lone multi-frame chunk,
and validates the decoded chunk's width, height, frame count, and component
count against it before writing:

File 1.2.826.0.1.3680043.10.999... (chunk 2) does not fit the volume it belongs
to. It decoded to 10x8x1 with 1 component(s), but the volume has room for 6x4x1
with 1 component(s). Every file in a volume must have the same Rows, Columns,
and SamplesPerPixel.

Files are identified by SOP Instance UID, since chunks carry no filename or
source URI. The closing advice is omitted for single-file volumes, where it is
meaningless. Only the offending instance is rejected.

One supporting fix, needed to make a rejection survivable:

A rejected chunk no longer wedges the loading state. computeStatus treated
anything but Loaded as still coming, so an errored chunk left the image
incomplete with loading never cleared: progress indicators ran forever and
image-stats never computed auto window/level. Errored is now terminal. An
image settles once every chunk is Loaded or Errored, and settling clears
loading. Status reaches complete only if at least one chunk loaded, so a
volume where everything was rejected settles without claiming to be a finished
image. Auto window/level then computes from the chunks that did load.

Scope

This contains the damage; it does not make heterogeneous series display
correctly. A rejected instance leaves its slot zeroed, so a scout in an axial
stack becomes a blank slice plus one named error rather than a volume of its
own. There is no benign case being preserved: the buffer is sized from the
first instance and the write is a raw copy into a fixed-size slot, so a
differing instance is either a RangeError, a smear, or transposed garbage.

The final solution is to partition on pixel geometry during categorize, as a
sibling of SeparateOnImageOrientation, so the mismatched instances become
their own volume and this guard never fires. That is a separate change: it
needs the itk-wasm build and it changes volume IDs, which appear in saved state
files. This guard is still worth keeping afterwards, because grouping and
allocation read metadata tags while the guard compares the size ITK actually
decoded, so a file whose tags disagree with its pixel data is caught here and
nowhere else.